解决Chrome 浏览器ERR | 您所在的位置:网站首页 › 解决谷歌浏览器的Google引擎无法使用的问题 › 解决Chrome 浏览器ERR |
目录 一、背景 二、下载编译工具depot_tools 三、下载Chromium源码 四、分析Chromium代码并加日志 四、编译Chrome 五、定位问题 六、解决方案 七、踩坑记录 一、背景最近公司客服同事经常反馈每到下午四点以后chrome浏览器经常会出现ERR_INSUFFICIENT_RESOURCES 异常,导致客服系统无法正常工作。主要特征就是新打开Tab时会报这个异常,在原来的tab内可以正常的使用。清理一下浏览器缓存,过不了多久还会出现。这个问题我们团队的前端小伙伴也没有遇到过,所以我们在网上也找了很多相关资料,发现有一个篇博客遇到的场景和我们遇到的场景较为相似,因此我们沿着这个思路尝试定位了一下,最终验证了是相同的问题,接下来我把整个的定位和解决的过程描述一下,希望对遇到相关问题的同学有所帮助。 二、下载编译工具depot_tools(在下载chrome源码时,确保能正常的访问google) deptool是下载和编译chromium的工具。使用git把deptool工具克隆到本地: git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git此时fetch、gclient等命令行工具其实已经可以通过绝对路径访问并执行了,不过为了后续操作方便,可以将其加入到PATH中 export PATH="$PATH:/path/to/depot_tools"完成后,在命令行里测试下 fetch 命令是否可用: which fetch 三、下载Chromium源码因为 gclient、fetch等工具核心下载代码的过程也是依赖于git的,所以有如下git全局设置建议调整下: git config --global http.postBuffer 524288000 git config --global core.precomposeUnicode true因为chrommium项目历史悠久,git仓库巨大无比,为更快的完成下载代码,可以忽略历史提交代码的方式拉取能够加快速度。 fetch --no-history chromium如果拉取失败可以执行以下命令继续拉取,此命令支持断点续传。 gclient sync 四、分析Chromium代码并加日志用VS打开Chromium/src/services目录,该目录是chrome的基础的系统服务层。搜索ERR_INSUFFICIENT_RESOURCES,发现有100多处,我们发现在services/network/url_loader_factory.cc中有如下代码 void URLLoaderFactory::CreateLoaderAndStartWithSyncClient( mojo::PendingReceiver receiver, int32_t request_id, uint32_t options, const ResourceRequest& resource_request, mojo::PendingRemote client, base::WeakPtr sync_client, const net::MutableNetworkTrafficAnnotationTag& traffic_annotation) { // 省略前面代码 bool exhausted = false; if (!context_->CanCreateLoader(params_->process_id)) { exhausted = true; } int keepalive_request_size = 0; if (resource_request.keepalive && keepalive_statistics_recorder) { const size_t url_size = resource_request.url.spec().size(); size_t headers_size = 0; net::HttpRequestHeaders merged_headers = resource_request.headers; merged_headers.MergeFrom(resource_request.cors_exempt_headers); for (const auto& pair : merged_headers.GetHeaderVector()) { headers_size += (pair.key.size() + pair.value.size()); } keepalive_request_size = url_size + headers_size; const auto& top_frame_id = *params_->top_frame_id; const auto& recorder = *keepalive_statistics_recorder; if (!exhausted) { if (recorder.num_inflight_requests() >= kMaxKeepaliveConnections || recorder.NumInflightRequestsPerTopLevelFrame(top_frame_id) >= kMaxKeepaliveConnectionsPerTopLevelFrame || recorder.GetTotalRequestSizePerTopLevelFrame(top_frame_id) + keepalive_request_size > kMaxTotalKeepaliveRequestSize) { LOG(ERROR) >101 [38514:19971:1103/151157.875321:ERROR:url_loader_factory.cc(182)] url_loader_factory.cc>>>>CreateLoaderAndStartWithSyncClient>>url:https://content-autofill.googleapis.com/v1/pages/ChNDaHJvbWUvMTA5LjAuNTM4MS4wEjMJBAwQwvyO8h4SBQ2RYZVOEgUNkWGVThIFDZFhlU4SBQ2BkPF8EgUNgZDxfBIFDZFhlU4SEAkcC8bFxOA28RIFDQbtu_8=?alt=proto [38514:19971:1103/151157.875475:ERROR:network_context.cc(933)] network_context.cc>>>>CanCreateLoader>>count101process_id:0 [38514:19971:1103/151157.875565:ERROR:url_loader_factory.cc(263)] url_loader_factory.cc>>>>ERR_INSUFFICIENT_RESOURCES [38514:19971:1103/151157.876158:ERROR:network_context.cc(926)] network_context.cc>>>>LoaderDestroyed>>process_id:0 count>>100分析发现每次创建新tab时,都会触发process_id:0 的进程,因为前端项目中用到了autofill功能,会不断的触发https://content-autofill.googleapis.com/v1/pages的请求,而本机又无法访问google,会导致process_id:0 的进程中未完成的请求数一直在累加,而我们公司的客服系统会持续工作8个小时往上。这就导致了当每次开启新的tab时会先执行process_id:0 进程的校验逻,进而导致了前面代码中的exhausted=true,但我们再次打开新的tab无论访问任何网站都会抛出ERR_INSUFFICIENT_RESOURCES这个异常。 六、解决方案我采用的方案是在本地配置host,将*.googleapis.com域名指向了127.0.0.1,这样.googleapis.com的请求会快速结束,进而不会触发chrome的阈值, 进而避免了exhausted=true的情况,后续再也没有收到客服团队反馈相关的问题。 七、踩坑记录1.如果开启了科学上网,仍然无法拉取代码 fatal: unable to access 'https://chromium.googlesource.com/chromium/tools/depot_tools.git/': Failed to connect to chromium.googlesource.com port 443 after 75123 ms: Operation timed out export https_proxy=http://127.0.0.1:7890 export http_proxy=http://127.0.0.1:7890 2.在克隆大型git仓库时出现问题: error: RPC failed; curl 18 transfer closed with outstanding read data remain (错误:RPC失败;curl 18传输已关闭,但仍有未完成的读取数据) 经查原因是curl的postBuffer的默认值太小,我们需要在终端重新配置大小: //设置全局http.postBuffer为200M,即2000x1024x1024=2097152000 bite //(如果目标实在大于200M,自行根据实际需求更改) git config --global http.postBuffer 209715200000 //改完后可查看现有git私有配置列表确定是否成功 git config --list 参考:分享一次替Boss直聘企业端Debug的经历 - 知乎 Mac上本地编译Chrome浏览器踩坑笔记(2021.02最新) - 知乎 |
CopyRight 2018-2019 实验室设备网 版权所有 |